A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. FIG. 1 graphically represents a Document Object Model (DOM) as provided by the World Wide Web consortium, which can be found at http://www.w3.org/TR/DOM-Level-2-Core/introduction.html. (The figure and some of the related description provided hereinafter are subject to Copyright (c) Nov. 13, 2000, World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231)
The DOM is a representation of a valid HTML and well-formed XHTML document. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term “document” is used in the broad sense—increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XHTML document can be accessed, changed, deleted, or added using the Document Object Model. As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. The DOM is a programming API for documents. It is based on an object structure that closely resembles the structure of the documents it models. For instance, consider the table shown below, taken from an HTML document (Web page) and graphically represented in FIG. 1:
<TABLE><TBODY><TR><TD>Shady Grove</TD><TD>Aeolian</TD></TR><TR><TD>Over the River, Charlie</TD><TD>Dorian</TD></TR></TBODY></TABLE>
In the DOM, documents have a logical structure which is very much like a tree; to be more precise, which is like a “forest” or “grove”, which can contain more than one tree. Each document contains zero or one doctype nodes, one root element node, and zero or more comments or processing instructions; the root element serves as the root of the element tree for the document. However, the DOM does not specify that documents must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented. The DOM is a logical model that may be implemented in any convenient manner. In this specification, the term structure model is used to describe the tree-like representation of a document. The term “tree” is used when referring to the arrangement of those information items which can be reached by using “tree-walking” methods. One important property of DOM structure models is structural isomorphism: if any two Document Object Model implementations are used to create a representation of the same document, they will create the same structure model, in accordance with the XML Information Set. (Note: There may be some variations depending on the parser being used to build the DOM. For instance, the DOM may not contain whitespaces in element content if the parser discards them.)
The name “Document Object Model” was chosen because it is an “object model” in the traditional object oriented design sense: documents are modeled using objects, and the model encompasses not only the structure of a document, but also the behavior of a document and the objects of which it is composed. In other words, the nodes in the above diagram do not represent a data structure, they represent objects, which have functions and identity. As an object model, the DOM identifies: the interfaces and objects used to represent and manipulate a document; the semantics of these interfaces and objects—including both behavior and attributes; and the relationships and collaborations among these interfaces and objects.
The structure of Standard Generalized Markup Language (SGML) documents has traditionally been represented by an abstract data model, not by an object model. In an abstract data model, the model is centered around the data. In object oriented programming languages, the data itself is encapsulated in objects that hide the data. The functions associated with these objects determine how the objects may be manipulated, and they are part of the object model.
The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability. The Document Object Model is not a way of persisting objects to XHTML or HTML. Instead of specifying how objects may be represented, the DOM specifies how XHTML and HTML documents are represented as objects, so that they may be used in object oriented programs. The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures. The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the W3C XML Information Set. The DOM is simply an API to this information set.
The Document Object Model, despite its name, is not a competitor to the Component Object Model (COM). COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document. The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. In the fundamental DOM interfaces, there are no objects representing entities. Numeric character references, and references to the pre-defined entities in HTML and XML, are replaced by the single character that makes up the entity's replacement.
The DOM specifies interfaces which may be used to manage XHTML or HTML documents. It is important to realize that these interfaces are an abstraction—much like “abstract base classes” in C++, they are a means of specifying a way to access and manipulate an application's internal representation of a document. Interfaces do not imply a particular concrete implementation. Each DOM application is free to maintain documents in any convenient representation, as long as the interfaces shown in this specification are supported. Some DOM implementations will be existing programs that use the DOM interfaces to access software written long before the DOM specification existed.
The proliferation of smartphones, tablets, laptops and televisions is creating the expectation and opportunity for a user experience to flow across these types of devices. At the same time, Web pages, such as but not necessarily limited to those using hyper transfer HyperText Markup Language (HTML) version 5 (HTML5) and related technologies, are increasingly viewed as an attractive means to deliver cloud based services to a wide range of network-connected devices for use of HTML and/or XML documents. HTML5 and Digital Living Network Alliance (DLNA) HTML5 remote user interface (RUI) are examples of various means contemplated by the present invention for multichannel video programming distributor (MVPDs), multiple system operators (MSOs) and other types of service providers to deliver their services through Web pages to a broad range of IP devices. In order for user experiences to flow across various types of IP devices, optionally when restrained to certain protocols/standards, a need exists for the devices and/or applications operable with the devices to enable multi-device use cases for various cloud-based services, such as but not necessarily limited to enabling multi-device use cases for remote control, discovery, collaboration and service migration.